SONET is one of the predominant transmitting and multiplexing standards for high-speed signals used in communications and computer networks today. The SONET protocol and architecture formats data into high-speed frames having a standard number of bytes. The basic building block of a SONET digital transmission system is a synchronous transport level one, or STS-1, frame which consists of 9 rows by 90 columns of bytes, for a total of 810 bytes. The frames are transmitted at a rate of 8,000 frames per second (or once every 125 microseconds) to provide a 51.84 Mbps signal rate. The STS-1 frame is transmitted one row at time, from top to bottom, and from left to right within each row. Therefore, the byte in row 1, column 1 is sent first, and the byte in row 9, column 90 is sent last. After the 90th byte is sent at the end of row 1, the next byte sent is the first byte in row 2, the byte in column 1. Because one frame is sent every 125 microseconds, SONET can maintain time-slot synchronization that is required for delivery of PCM voice data (8 bits at 8,000 times per second or 64 kbps). SONET also adheres to frame synchronization time with asynchronous network standards such as DS-1, E-1, and DS-3.
Higher rate SONET formats essentially follow the same format of the STS-1 protocol. All SONET frames contain exactly nine rows and are transmitted at 8,000 times per second. The only variable is the number of columns, or subcolumns. For example, an STS-3 frame consists of 9 rows and is sent 8,000 times per second; however, an STS-3 frame is not 90 columns wide, but is three times wider. Therefore, the STS-3 frame is 270 columns wide and its corresponding transmission rate is 155.52 Mbps. The STS-3 overhead columns are multiplied by three a well, as are the SPE capacity columns. Typically, the STS-3 frame comprises three STS-1 signals interleaved as alternating columns within the STS-3 frame. Therefore, the first column of the STS-3 frame is the first column of a first STS-1 signal, the second column of the STS-3 frame is the first column of a second STS-1 signal, and so on. Similarly, higher order STS-N formats (e.g., STS-12, STS-48, etc.) have proportionally wider frame formats containing a greater number of interleaved columns and faster bit transmission rates.
FIG. 1 illustrates the data format for a SONET STS-1 frame 100 having 9 rows by 90 columns of bytes (otherwise referred to as “octets”). The first three columns 102 are allocated for transport overhead (TOH) information which includes section overhead (SOH) and line overhead (LOH) data. As is known in the art, SOH data deals with the transport of an STS frame across the physical medium and controls functions such as framing the SONET data stream, scrambling and error monitoring. The LOH data deals with the reliable transport of the payload between line terminating equipment. FIG. 2 illustrates a typical format for the transport overhead portion of the STS-1 frame of FIG. 1 consisting of 27 octets (9 rows×3 columns). As shown in FIG. 2, the first three rows of the three transport overhead columns provide nine octets that are allocated for SOH data and includes information such as: framing octets (A1, A2); STS-1 ID number (C1); section error monitoring (B1); section orderwire channel (E1); section user channel (F1); and section data communication channels (D1-D3). The remaining six rows of the three transport overhead columns include eighteen octets that are allocated for LOH information which includes: STS-1 pointer offset (H1, H2); STS-1 pointer action byte (H3); line error monitoring (B2); automatic protection switching channel (K1, K2); line data communication channel (D4-D12); growth (Z1, Z2); and line orderwire (E2).
The remaining 87 columns of the STS-1 frame consist of 783 octets (9 rows×87 columns) that are allocated for “user” data, otherwise referred to as the “payload.” Referring again to FIG. 1, the structure of the payload is defined by a synchronous payload envelope (SPE) 200 which contains 783 octets of data and is transmitted at 8,000 times per second. The first column 210 of SPE 200 contains additional overhead information, commonly referred to as path overhead (POH) data, as well as the actual user data. The POH data 210 is stored in one “column” or nine bytes of the SPE. The first POH byte indicates the first byte of the SPE. FIG. 3 illustrates a typical data format for path overhead data 210 (FIG. 1) contained within an SPE. The POH data is used to monitor and manage the transport of network services such as DS1 or DS3, for example, between path terminating equipment (PTE) and includes information such as: path trace (J1); path error monitoring (B3); path signal label (C2); path status (G1); path user channel (F2); multiframe indicator (H4); and growth/future use (Z3-Z5).
In a perfect world, it would make sense to assign the first byte of the SPE as the 4th byte in row 1 of the STS-1 frame so that the SPE is aligned with the overall SONET frame structure. However, in reality, the clocks used in networks to time bit streams do not always cooperate and remain perfectly synchronized. Factors such as jitter and phase differences make it difficult to fix the SPE inside the SONET frame in all cases and at all times. The SPE, therefore, does not have to be aligned with the first row and fourth column of the SONET frame. Consequently, the POH can begin at any byte position within the SPE capacity which typically results in the SPE overlapping into the next frame. FIG. 4 illustrates how a SPE may be mapped into a SONET frame when there are phase differences between the incoming and outgoing payloads. In other words, the SPE determines how the customer's data is carried on the SONET system.
Because the SPE can begin at any position within the information payload section of the frame, a mechanism is necessary to locate the SPE at the receiving side of the SONET link. This mechanism is provided by bytes designated as pointer bytes H1 and H2 and pointer action byte H3 contained within the LOH section of the transport overhead data discussed above. The H1 and H2 pointers are comprised of one byte each and are used to indicate the offset between the pointer bytes themselves and the beginning of the SPE. Therefore, the H1 and H2 pointers allow for the dynamic alignment of the SPE within the allowable capacity of the envelope itself. The protocol governing the values and functions of bit positions within the pointers to indicate the SPE start position is well-known in the art and need not be repeated here. Suffice it to say that the H1 and H2 pointer bytes always point to the first byte of the SPE, which is the start of the POH bytes as well.
The pointer action byte H3 is allocated to compensate for the SPE timing variations mentioned above. In the course of otherwise normal operation, the arriving SPE data rate will exceed the frame capacity. This means that within a 125-microsecond period, more than 783 bytes may be ready to be sent out in an SPE. If this excess were to be less than 8 bits, the extra bits would be just buffered sequentially and sent out as the first bits of the next frame; however, when a full byte (8 bits ) has accumulated in the buffer, the pointer action byte is used to carry the “extra” byte. This is called a negative timing justification and is governed by strict rules of SONET equipment operation. Conversely, a positive time justification is used when 783 bytes are not in the CPE buffer to fill the SPE exactly.
The H3 byte is provided in all STS-1 signals within an STS-N signal. The value contained in this byte, when it is not used to carry SPE data during a negative justification is not defined and, hence, ignored. The H1 and H2 pointer bytes tell the receiver when the H3 byte is used for useful information. This byte is necessary due to the variations in timing across different service provider's networks or when CPE clocking feeds a SONET link. The mechanism of “floating SPEs” with the H1, H2 and H3 bytes is complex and many service providers desire to minimize its use. Many of these service providers lock the value of the H1 and H2 bytes to 522 (20A in hex), which points to row 1, column 4 of the next SONET frame. This method of “locking” the SPE to a fixed position in the STS-1 frame minimizes pointer justifications, but increases buffer requirements and management in the face of continued timing jitter.
In addition to user data, the SPE contains path overhead (POH) bytes. These are processed at SONET STS-1 terminating equipment because they travel as part of the payload envelope and are processed everywhere it is processed. The SPE contains nine bytes of POH. These bytes form a “column” in the SPE portion of the SONET frame, meaning the POH bytes are always in a column. However, because the position of the SPE can “float” within the STS-1 frame Information Payload area, the position of the POH bytes can float as well. As mentioned above, the functionality and operation of the POH data is well known in the art and, hence, need not be further described herein.
Because the POH data is vital to the function of monitoring and managing the transport of various services such as DS1, DS3, ATM, etc. between path terminating equipment, it is desirable to buffer the POH data for processing with software and/or hardware mechanisms during SONET frame transmission. Using the pointers H1 and H2, and the pointer action byte H3, of the LOH data described above, the start of the SPE and hence the start of the POH may be adjusted and monitored even when their positions vary within a frame due to synchronization errors or timing jitters. Once the start of the POH is determined, the positions of the remaining bytes of the POH within a SPE can be calculated. For higher rate STS frames (e.g., STS-3, STS-12, STS-48, etc.), the start of more than one SPE may be defined within a single frame. For example, in a STS-3 frame, three separate SPEs may begin at three distinct byte positions within the payload area of a frame. Additionally, there will be three separate sets of SOH and LOH data within the STS-3 frame. Each set of LOH data will contain the pointers H1 and H2 to point to a corresponding starting position of POH data and a SPE. After these starting positions are determined, the remaining byte positions of each POH can be calculated.
Different bytes in the overhead of SONET frames are handled with different mechanisms. With regard to certain of those bytes, the prior art uses one of the two following buffering techniques. For an SPS-48 SONET signal, for example, a first technique utilizes two sets of 48×9 byte buffers implemented on a single chip. Additionally, there is a bus from the chip to a field programmable gate array (FPGA). These double buffers are operated in a “ping pong” fashion such that when data is being written into one of the buffers, data is being read from the other buffer, and vice versa. Hardware elements switch between the two buffers at the end of each SONET frame (i.e., every 125 microseconds). When a read operation from a first buffer is performed, the bus is used to transport the contents of the first buffer into the FPGA for processing. A processor then accesses the resulting data from the FPGA for further processing. At the same time, the second buffer is switched to receive incoming POH bytes corresponding to a second frame. The above process repeats for the second buffer and SPE overhead bytes are written into and read from each of two buffers in alternating read and write operations.
One of the primary disadvantages with the above-described prior art technique of implementing dual buffers is its difficulty, or inability, to detect and properly store, transport and process POH bytes when positive and/or negative timing justifications effect the number of POH bytes contained in one SONET frame. As described above, due to synchronization jitters and timing variations between path terminating equipment (PTE), SPEs and their respective POH bytes are not exactly aligned with the bytes of a single SONET frame. Rather, the SPE's and POH bytes typically “float” within two SONET frames. Therefore, pointers H1 and H2, and pointer action byte H3, are used to compensate for these timing variations and perform negative timing justifications and positive timing justifications, as necessary. As a result of performing these negative and positive timing justifications, a condition occasionally arises in which a SONET frame will contain either eight POH bytes or ten POH bytes of a STS-1 signal, instead of the normal nine bytes. This condition is known in the art and is referred to herein as a “corner case” condition. Recall that the switching between the two buffers is synchronized with SONET frame transmission time rather than with SPE transmission times. However, the transmission of SPEs and POHs is not necessarily aligned with the transmission of SONET frames. Thus, for example, if a SONET frame contains only eight POH bytes of a respective SPE, only those eight POH bytes are written to one of the dual buffers during a write operation. Therefore, the processor must recognize there is a missing POH byte and update that POH byte. If the SONET frame contains ten POH bytes, there is a possibility that the tenth POH byte, which may be the first POH byte of the next SPE, will overwrite the first POH byte of the current SPE. Thus, a miscorrelation of path overhead data and user data may occur, adding to the complexity of processing user data.
Another disadvantage with the above-described prior art approach is its lack of flexibility in buffering the POH bytes. For example, hardware elements may sometimes process some or all of the necessary POH bytes of a respective SPE. Therefore, only a few, or none, of the POH bytes for that SPE may need to be buffered for further processing by software mechanisms. Regardless of this condition, the dual-buffer technique still stores all POH bytes of a SPE within a respective buffer even when some or all of them need not be processed. This is an inefficient utilizing of buffer memory.
In addition to the disadvantages described above, further limitations of this system include: (1) the requirement of an FPGA; (2) two sets of buffers require more space on the chip and increase chip costs; (3) the two set of buffers are not accessible by the CPU; and (4) a dedicated bus is required to transport data from the chip to the FPGA. All of these disadvantages add to the cost and complexity of this prior art method of buffering and processing overhead data.
To overcome the disadvantages of the above-described prior art technique, a second prior art technique uses only one 48×9 byte buffer. However, this buffer is partitioned into a first 48×4 byte buffer (referred to herein as the “upper buffer”) and a second 48×5 byte buffer (referred to herein as the “lower buffer”). Each of the forty eight columns of the upper buffer corresponds to a respective STS-1 signal interleaved in the STS-48 signal. Each column of the upper buffer stores the first four POH bytes of a respective SPE. Similarly, each of the forty eight columns of the lower buffer store the last five POH bytes of the respective SPE contained within the STS-48 frame.
Referring to FIG. 5A, a block diagram of a 48×4 byte upper buffer is illustrated. Each column of the upper buffer stores the first four POH bytes of a respective SPE. A flag is associated with each set of four bytes of SPE overhead data. FIG. 5B illustrates an exemplary 48-bit flag buffer used to indicate when particular columns of the upper buffer are full. When the first four bytes of POH of a SPE are stored in a column of the upper buffer, a flag is set and stored in a corresponding position of the flag buffer to indicate the availability of the first four bytes of POH data for processing. Similarly a second 48-bit flag buffer (not shown) is used to indicate when particular columns of the lower buffer (not shown) are full (i.e., contain the last five POH bytes of a respective SPE).
In order to read the POH bytes stored in the upper and lower buffers, software periodically polls (e.g., every 32 microseconds) the first and second flag buffers. In one embodiment, a microprocessor reads and automatically clears each flag from the flag buffers. In this way, the latency period between the time the flag buffer is read and the time when the flag buffer is ready for storing flags for a next read cycle is minimized. For each location of the first and second flag buffers in which a flag is set, the corresponding columns of the upper and lower buffers will be accessed for processing. Because the first four POH bytes of a respective SPE will always be available before the last five POH bytes, the POH bytes of a single SPE are typically read in a toggle fashion wherein the first four POH bytes of the SPE are read in a first read operation and the last five POH bytes of the SPE are read in a later read operation. Additionally, since any set of four POH bytes or five POH bytes of different SPEs may be available individually and irrespective of the availability of POH bytes of other SPEs, the timing associated with receiving and processing POH bytes is not based on SONET frame transmission time. Thus, the “corner case” condition caused by timing justifications experienced by the dual-buffer, prior art methodology is largely eliminated in this prior art solution.
A primary disadvantage of this second prior art technique, however, is that it requires extensive processing by a microprocessor to handle the polling of flags and the processing of the bytes in their respective buffers. Additionally, each of the POH bytes must be mapped into their corresponding locations within the upper (48×4) or lower (48×5) buffers. As the data rate increases (e.g., STS-48 and STS-192) the burden on the processor increases to keep track of the incoming POH bytes by checking the corresponding flags within the flag buffers, calculating buffer locations, and reading buffer and processor data. All of the above functions must be performed within specified time limits to avoid data overflow problems. Thus a primary limitation of this technique includes the processing power of microprocessor.
Similar to the first prior art technique described above, this second prior art approach also suffers from its lack of flexibility in buffering the POH bytes. Even if only a few, or none, of the POH bytes of one or more SPEs are desired for processing, all the POH bytes of all SPEs are eventually stored in corresponding columns of the upper and lower buffers. This is inefficient.
Thus, there is a need for an improved method and system for buffering overhead bytes of SPE's within SONET frames which overcome the limitations of the prior art methods and systems.